개요

오픈톡방에서 어떤 분이 질문을 올리셨다.

이렇게 마운팅을 진행했을 때, 호스트 노드에 파일이 제대로 생기지 않는다는 것.
hostPath에 마운팅을 한 후, 그 위로 ConfigMap을 마운팅하는 것이다.
그렇게 노드에서 configmap 정보를 받아보고 싶으셨던 듯하다.

나는 이 문제가 마운트 전파에 있다고 생각했다.
그래서 어렵지도 않으니 혹시나 하는 마음에 테스트를 진행해봤다.

세팅

EKS 1.31 버전을 써서 진행한다.

apiVersion: v1
kind: Pod
metadata:
  name: cm
spec:
  containers:
  - name: cm
    image: centos
    command: ["sh", "-c", "while true; do sleep 60; done"]
    volumeMounts:
    - name: host
      mountPath: /test
      mountPropagation: Bidirectional
    - name: config
      mountPath: /test/config
    securityContext:
      privileged: true
  volumes:
    - name: host
      hostPath:
        path: /opt
    - name: config
      configMap:
        name: test
  terminationGracePeriodSeconds: 1

먼저 파드는 이렇게 만들었다.
보다시피 hostPath에 대해 Bidirectional 설정을 넣어서 컨테이너에서의 마운팅이 마운팅을 허용해준 주체에게 전달될 수 있도록 했다.
이때 privileged를 설정해야만 했다..
근데 사실 hostPath를 사용할 수 있을 정도의 파드라면 애초에 권한이 막강한 녀석이긴 해서 privileged가 안티 패턴이라 한다면 사실 hostPath 부분부터 걸고 넘어져야 하지 않을까 싶다.

configmap은 대충 만들었다.

테스트

노드에 들어가서 확인해보니, 실제로 제대로 마운팅이 된 것이 확인된다.
사실 그것보다는 직접적으로 configmap의 디렉토리 상태를 보는 게 조금 신기했다.
동적으로 값을 변경할 수 있도록 지원하기 위해 먼저 업데이트 시간 기준으로 디렉토리를 만들고, 이걸 심볼링 링크로 제공해주는 것 같다.
사실 이 부분은 명확하게는 잘 모르겠다.

configmap 동적 변경

호로록 데이터를 추가해본다.

15초 정도 시간이 지난 것 같은데, 데이터가 추가된 것이 확인된다.

파드 삭제 시

실험을 위해 기존 파드를 삭제하자 마운트가 풀리면서 컨피그맵의 내용물도 다 사라졌다.
configmap은 평소에 etcd에 저장돼있다가 컨테이너가 마운팅할 때만 파일시스템으로 구성되며, 완벽하게 라이프사이클도 같이 한다는 것을 알 수 있다.

신기한 건, 이후에 디렉토리를 지울 수 없다는 것..

/dev/nvme0n1p1 on /opt/config type xfs (rw,noatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,sunit=1024,swidth=1024,noquota)

mount로 확인해보니 마운팅이 해제되지 않은 모습이다.
umount 해주니 바로 삭제가 가능해졌다.

mount propagation 설정을 하지 않을 시

이번에는 마운트 전파 필드만 삭제하고 다시 진행해봤다.
디렉토리는 생기지만, 실제 내용물은 들어가지 않는다.
마운팅이 전파가 되지 않았기 때문이다.

결론

마운팅 전파를 호스트로 하고 싶다면 특권 권한을 주는 수밖에 없다.

configmap가 마운팅될 때는 내부에 동적 변경이 이뤄질 수 있도록 추가적인 디렉토리 세팅이 이뤄진다.
이 부분에 대해서 추가적으로 탐구하게 된다면 다른 토픽으로 작성해야겠다.

관련 문서

참고